Amazon Redshift

Fixed cost.

Tunable table design.

Need to provision warehouse for highest capacity.

No real separation between computing and storage (even when considering Spectrum).

All users share the same infrastructure resulting in frequent 100% utilization error messages.

A leader node can become a bottleneck for too many concurrent aggregate queries.

Constant killed queries.

Not much performance boost in terms of the cache.

Users perceived the data warehouses as incapable of supporting widespread usage throughout the enterprise.

Since it's part of AWS it is fairly quick and easy to set up.

You can add nodes fairly quick to expand the data needs.

Performance from the analytics reports accessing Redshift is really good.

Better database management when looking up table metadata or sizes of tables.

Need a better query analyzer.

Finding errors during a data load can be a little daunting at times.

Cheaper cost to run.

Readily available and can easily expand.

Part of the AWS echo system which is great, because our Analytic tools are also part of AWS.

Redshift seems to be as fast processing a large dataset as it is with a small one. It seems, when the dataset size is significantly increased (10x, 100x, 1000x, etc.), DML queries are often executed within the same amount of time.

Redshift has a powerful graphical admin tool to monitor the ongoing queries in real time and historically.

Easily expandable capacity. Automatic snapshots that eliminate the need for managing backups. Simple database maintenance strategies with the VACUUM and ANALYZE commands.

Abundance of detailed documentation and tutorials.

It could benefit from adding data integrity and programming tools common to other database management systems.

Amazon Redshift is based on PostgreSQL 8.0.2. That version of PostgreSQL was released in December 2006. While PostgreSQL was much improved since then, the new features were not implemented in Redshift. Many basic features are missing from it.

Primary keys can be declared but not enforced. Referential integrity (foreign keys) can be declared but not enforced. UNIQUE and CHECK constraints are not supported and cannot be declared.

IDENTITY can be declared on a column, and Redshift will put unique values into it. However: IDENTITY values in the newly inserted rows won’t be incremental or sequential. To implement a sequential number, you need to write your own custom code.

There are no stored procedures in Redshift. We are writing SQL script files, and then parsing and running them one statement at a time from a Python program. This also enabled us to implement execution-time error logging.

In SQL scripts, to check for the row count of affected rows, a complicated join query against some system tables or views has to be executed.

Data Control Language (DCL) does not exist. No statements like IF, WHILE, DO, RAISERROR, etc.

On performance of views… Views do not “pass-through” a query parameter which is a potential problem for performance.

When selecting against a view with the WHERE clause outside of the view, the inner query of the view will be executed first without consideration for the WHERE clause, and only then the WHERE clause will be applied.

Certain clauses of SQL work many times faster than other clauses. So be careful and test your statements for performance earlier rather than later, especially if working with a large data set.

There was a situation when DELETE FROM JOIN was unacceptably slow. Replacing JOIN with the USING clause made DELETE instantaneous.

Our company is moving to the AWS infrastructure, and in this context moving the warehouse environments to Redshift sounds logical regardless of the cost.

Development organizations have to operate in the Dev/Ops mode where they build and support their apps at the same time.

Hard to estimate the overall ROI of moving to Redshift from my position. However, running Redshift seems to be inexpensive compared to all the licensing and hardware costs we had on our RDBMS platform before Redshift.

Fast analytical queries. The shared nothing and column oriented architecture makes querying very quick compared to databases like Oracle that are designed for OLTP. Scaling is a synch since you can scale out by adding more nodes.

Easy table modelling. The only tough decisions you have to make are what your distribution schemes and sort keys are going to be. This is a lot easier than defining partition and index schemes in databases like Oracle or MySQL.

Not much maintenance. Almost everything is managed by Amazon. The only exception is table vacuuming and analysis. I was able to program simple ETL jobs to perform this.

Works with pretty much anything that works with Postgres. It's hard to find a tool that it isn't compatible with.

Lack of enforced constraints (except NOT NULL column constraints). You have to be very careful in your testing to make sure that you aren't duplicating rows.

No stored procedure support. Everything must be accomplished through ETL

Write operations are very slow and complex.Native SQL row level INSERT and UPDATE statements take an extremely long time to execute. In order to get around this for external data that needs to be loaded, you have to bulk load the data from a flat file to a stage table, then upsert the data from the stage table to your destination table. For data already present in the database, ELT is the only viable way of transforming the data.

No good native data modelling tools.

Random nondescript errors happen occasionally. The error messages are not decipherable and forums will have no clues as to what happened. It is just a fact of life.

No trigger support.

OLTP style queries are painfully slow. Don't even think about using Redshift for OLTP...

Redshift has had a very positive impact on our business. It has been used to provide analytics on marketing campaigns to boost revenue.

Redshift is instrumental in our payment collection business processes. It powers everything from who gets called to who gets sent collection emails.